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The Inter- Integrated Circuit Bus 
("I 2 C Bus" for short) is a two- 
wire, synchronous, serial inter- 
face designed primarily for 
communication between intel- 
ligent IC devices. The He bus offers sev- 
eral advantages over "traditional" seri- 
al interfaces such as Microwire and 
RS-232. Among the advanced features 
of I 2 C are multimaster operation, auto- 
matic baud-rate adjustment, and "plug- 
and-play" nerwork extensions. 

Mention the 1 2 C bus to a group of 
American engineers and you'll likely get 
hit with an abundance of blank stares. 
I say American engineers because un- 
til recently the I*C bus was primanly a 
European phenomenon. Within the last 
year, however, interest in I 2 C in the 
United States has risen dramatically. 
Embedded systems designers are real- 
izing the cost, space, and power sav- 
ings afforded by robust serial interchip 
protocols. 

The idea of serial interconnect be- 
tween integrated circuits is not new. 
Many semiconductor vendors offer de- 
vices designed to "talk" via serial links 
with other processors. Current examples 
include Microwire (National Semicon- 
ductor), SPI (Motorola), and most re- 
cently Echelon's Neuron chips. In all cas- 
es, the goal is the same: to reduce the 
wiring and pincount necessary for a par- 
allel data bus. It simply does not make 
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economic sense to route a full-speed 
parallel bus to a slow peripheral. 

Unfortunately for most serial-bus- 
capable devices, the choice of a bus 
protocol will dictate the CPU architec- 
ture. For example, only two CPU ar- 
chitectures implement an on-chip I^C 
port. If your choice of architecture pre- 
cludes use of these architectures, men 
your only option is to implement the 
protocol in software. 

The software implementation of the 
protocol discussed in this article 
came about as a result of an implicit 
challenge during a staff meeting One 
of our managers proposed that we hire 
a consultant to write a software I*C driv- 
er for the Intel 80C186EB embedded 
processor. Being somewhat new to the 



group. I took exception (although not 
verbally!) to his suggestion. A weekend 
of intense hacking later, 1 presented the 
first prototype of the driver. My reward? 
I got to write a generic version of the 
driver for general distribution. 

Design Trade-offs 

Three distinct tasks are involved in im- 
plementing the l*C protocol: watching 
the bus. waiting for a specific amount 
of time, and driving the bus. This be- 
came apparent when I flowcharted 1 
byte of a typical bus transaction; see 
Figure 1. The time delays associated 
with creating the bus waveforms would 
normally have been relegated to the 
80C186EB's on-chip timers. I could not. 
however, assume that the end users of 
my code would be able to spare a timer 
for the software 1^ port. I had to forego 
the elegance (and to some extent ac- 
curacy) of the on-chip timers for the 
sledgehammer approach of software 
timing loops. Luckily, the 1^ protocol 
is extremely forgiving with regard to 
timing accuracy. The decision to use as- 
sembly instead of a high-level language 
stemmed directly from the need to con- 
trol program-execution time. I had nei- 
ther the time nor the inclination to hand- 
tune high-level code. 

Having made the decision to use as- 
sembly language. I faced my next proh- 
lem: Could I make the code portable? 
Intel offers a plethora of CPU and em- 
bedded-controller architectures. Would 
it be possible to make the code some- 
what portable between disparate as- 
sembly languages? I found my answer 
in the use of macros. 
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All the basic building blocks of the 
I^C protocol (watching, waiting, and do- 
ing) can be compartmentalized into dis- 
tinct macros. The algorithms that make 
up the I^C driver are written with these 
macros as the framework. You don't 
need to understand the intricacies of the 
I^C protocol to port these routines — 
you just need to know how to make 
your CPU watch, wait, and do. 

For example, a h.7_uS delay is a com- 
mon event during a transfer. The macro 
%Wait_4_ 7_uS implements just such a 
delay by using the S086 LOOP instruc- 
tion with a couple of NOPs for tuning; 
see Example Ua). Total execution time 
is readily calculated from instruction tim- 
ing tables. The same macro is ported to 
the i960 architecture in Example Kb). 
Although I am a neophyte when it 
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1 1: Flowchart of process for 
transmission of a single bit 



comes to i960 programming, I had no 
problems porting the core macros. 



A few words about the target hardware 
are in order before I discuss the code. 
Any implementation of the I^C protocol 
requires two open-drain (or open-col- 
lector), bidirectional port pins for the 
Serial Clock (SO.) and Serial Data (SDA) 
lines. The code in this article was de- 
signed for the 80C186EB embedded pro- 
cessor, which has two open-drain pons 
on-chip. The two pins. P2.6 (SCL) and 
P2.7 (SDA). are part of a larger 8-bit 
port. Processors without open-drain I/O 
pons can easily implement I^C with the 
addition of an external open-collector 
latch. 

Two special-function registers. P2PIN 
and P2LTCH, are used to read and write 
the state of the port pins. The 80C186EB 
allows the special-function registers to 
be located anywhere in either memo- 
ry or I/O space. For this implementa- 
tion. I chose to leave the registers in 
I/O space, even though this limited my 
choice of instructions. The 80186 ar- 
chitecture does not provide for read- 
modify-write instructions in I/O space 
(an AND to L'O. for example); it can 
only load and store (IN and OUT). So 
why did I limit myself? Again. I had to 
assume the lowest common denomi- 
nator for our customers when design- 
ing my code. 

Building tfw FronwworK 

Early on in development. I decided to 
partition my code macros according BO 
physical processes involved in the I^C 



protocol. Code not directly involved in 
rnimicking the actioas of a hardware 1^ 
port was not written as macros For ex- 
ample, the code necessary to access the 
stack frame is not written as a macro, 
whereas the code needed to toggle the 
clock line is. TliLs was done to isolate 
architecture-dependent code sequences 
from the more generic I'C functions. 
Macros were also not used for 'gray ar- 
eas" such as the shifting of serial data, 
which is both architecture dependent 
and physical in nature. The 1-C func- 
tions that passed the litmus test fell in- 
to the three aforementioned categories 
of watching, waiting, and doing. 
" The "waiting" macros provide a fixed- 
minimum time delay. They are imple- 
mented using a simple LOOP S delay. 
The LOOP instruction decrements the 
CX register, then branches to the target 
(in this case itself) if the result is non- 
zero. The delay is (n-l)»I5+5 clocks, 
where n Ls the starting value in the CX 
register. All the delays were calculated 
assuming a 1 6-MHz clock rate (62.5 
nanoseconds per clock). The code still 
works at lower CPU speeds because the 
I^C protocol only specifies minimum 
timings. In fact, the delay macros are 
only "accurate enough." providing tim- 
ings as close as I could gel to the spec- 
ified minimum without undue tuning. 

The "watching " macros are "spin-on- 
bit" polling loops. These pieces of axle 
wait tor a transition on the appropnate 
r*C line to occur before allowing execu- 
tion to continue. There are two polling 
macros for each of the CWO l-C signal 
lines; one for high-to-low transitions and 
one for low-to-high transitions. The 
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*»DEFINE(Wa:t_4_7_uSI ( 

mov cx, 5 
loop S 

nop 

) 


i 4 clocks 

; 4»15o = 65 clocks 

; 3 Clocks 

; 1 clocks 

; local * 75 clocks 

1 75 • 62.5ns • 4.69uS (close enough) 


(b) 




define (Wai:_4_7_uS, ' 




Ida 0x17, r4 

Ob: cspdeco 0. r4 
fane.-. Ob 


» instruction .-ray be issued -.r. parallel 
» so assume no clocks. 

• compare and iecrement counter in r4 

• if !=0 brancr. back (predict taken 

• branch) 
* 

« The cnpdeco and bne.t toget.-.er take 3 
' clocks in parallel 

• 0x17 (25 deciaiall * 3 = tlscka 
■ at 16MHz this is 4.69uS 



Example 1: taj 430006 implementation ef4 7_«S unit macro tht S0960CA 
implementation of 1 uait macro 

Dr. Out^ts journal. June I'm 



June 1992 



1-281 



Philips Semiconductors Microntrolter Products 





polling of the SCL line that gives rise to 
an important feature of 1^; automatic, 
bit-by-bil baud-rate adjustment. Any de- 
vice on the bus may hold the clock 
line low in order to stall the bus for 
more time (a serial wait state). The oth- 
er devices on the bus are then forced 
to poll the SCL line until the slow de- 
vice releases control of the clock. 

The %Get_SDA_Bit macro also falls 
under the category of "watching." Its 
function is simply to return the state of 
the SDA line without waiting for a tran- 
sition. %Get_SDA^Bit is used primarily 
to pull the serial data off the bus when 
the clock is valid. 

The "doing" macros control the state 
of the clock and data lines. As with the 
polling macros, there are four types — 
one for each transition of the SCL or 
SDA lines. The "doing" macros are 
named to reflect the physical operations 
they perform. For example, %Dnve_ 
SCL_Low always drives the SCL line to 
a low state. %Release_SCL_High, on the 
other hand, relinquishes control of the 
SCL line, which may then be pulled high 
or driven low by another device on the 
bus. A read-modify-write operation is 
used for the bit manipulation so that the 
other 6 bits of Port 2 are not affected 
by the 1*C operations. 

Getting on the Bus 

Three procedures were created using 
the macro framework. I'll describe on- 
ly the master transmit (Listing One, page 
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Figure 2: Flowchart Jar I J C transmit 
procedure. 
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106) and master receive functions (List- 
ing Two, page 108), as they represent 
the needs of most I*C users. The slave 
procedure is long and intricate and will 
not be described here. 

An I*C master transmission proceeds 
as follows: 

1. The master polls the bus to see if it 
is in use. 

2. The master generates a start condi- 
tion on the bus. 

3. The master broadcasts the slave ad- 
dress and expects an acknowledge 
(ACK) from the addressed slave. 

4. The master transmits or more bytes 
of data, expecting an ACK following 
each byte. 

5. The master generates a stop condi- 
tion and releases the bus. 

The stack frame for the master trans- 
mit procedure. I2CXA.A86, includes a 
far pointer to the message for transmis- 
sion, the byte count for the message, 
and the slave address. Far pointers and 
far procedure calls are used in ail the 
procedures. No attempt was made to 
conform to a specific high-level lan- 
guage calling convention, although such 
a conversion would be trivial. The pro- 
cedures save only the state of the mod- 
ified segment registers. 

The master transmit procedure per- 
forms error checking on the passed pa- 
rameters before attempting to send the 
message. The maximum message length 
is set at 64 Kbytes by the segmentation 
of the 80186 memory space. This re- 
striction could be removed by includ- 
ing code to handle segment boundaries. 
The transmit procedure also checks the 
direction bit in the slave address to en- 
sure that a reception was not erro- 
neously indicated. Errors are reported 
back to the calling procedure through 
the AX register. (The exact code is in 
Listing One.) 

The first step in sending a message is 
getting on the l 2 C bus. The macro 
%Check_For_Bus^Free simply polls the 
bus to determine if any transactions are 
in progress. If so, the transmit proce- 
dure aborts with the appropriate error 
code. If the bus Is free, a start condition 
is generated. The MM condition is de- 
fined as a high-to-low transition of SDA 
with SCL high followed by a 4.7_uS 
pause. These waveforms are easily gen- 
erated with the %Drive_SDA_Low and 
%Wait_4_ 7juS macros. 

All communication on the I^C bus be- 
tween the stop and start conditions, in- 
cluding addressing and data, takes place 
as an 8-bil data value followed by an 
acknowledge bit. This lead to the nat- 
ural nested loop structure for the body 
of the procedure; see Figure 2. 



The inner loop is responsible for 
transmitting the 8 bits of each data byte. 
Each transmitted bit generates the ap- 
propriate data (SDA) and clock (SCL) 
waveforms while checking for both se- 
rial wait states and potential bus colli- 
sions. A bus collision occurs when two 
masters attempt to gain control of the 

Three distinct tasks 
are involved in 
implementing the 

I 2 C protocol: 
watching the bus, 
waiting for a specific 
amount of time, and 
driving the bus 

bus simultaneously. The I^C protocol 
handles collisions with the simple rule: 
"He who transmits the first on the SDA 
line wins the bus." To ensure that we 
(the master transmit procedure) own the 
bus. the SDA line is checked whenev- 
er transmitting a 1. If a is present, then 
a collision has occurred (because an- 
other master is pulling the line low), 
and the transfer must be aboned. 

Control is turned over to the outer 
loop after the 8 bits of data (or address) 
have been transmitted. The outer loop 
immediately checks for an acknowledge 
from the addressed slave. The transfer 
is aborted if an acknowledge is not re- 
ceived. At the end of the ACK bit the 
message length counter is decremented. 
Control is returned to the inner loop if 
more data remains, otherwise a stop con- 
dition is generated and the master traas- 
mit procedure terminates. 

Registers are used for intermediate re- 
sult storage throughout the body of the 
procedure. For example, the AH reg- 
ister is used to hold the current value 
(either address or data) being shifted 
onto the SDA line. This eliminates the 
need for local data storage within the 
procedure. 

On the Receiving End 

The steps involved in an I^C master re- 
ceive transaction are almost identical to 
those in transmission: 

1. The master polls the bus to see if it 
is in use. 

2. The master generates a start condi- 
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tion on the bus. 

3. The master broadcasts the slave ad- 
dress and expects an ACK from the 
addressed slave. 

4. The master receives or more bytes 
of data and sends an ACK to the slave 
after each byte. The master signals 
the last byte by not sending an ACK. 

5. The master generates a stop condi- 
tion and releases the bus. 



A far pointer to the receive buffer is 
passed on the stack to the master re- 
ceive procedure. The remainder of the 
parameters — slave address and mes^ 
sage count — are identical between the 
two procedures. The received message 
length is fixed at 64 Kbytes, again be- 
cause of segmentation. The error-check- 
ing, bus-availability sensing, and start- 
condition generation sections of the 
receive procedure are lifted verbatim 
from the transmit code. 

The structure of the receive proce- 
dure differs slightly once the stan con- 




Figure 3: Flowchart for !2C receive 
procedure. 



dition has been generated; see Figure 
3. The slave address is transmitted us- 
ing one iteration of the transmit proce- 
dure's outer loop. Control is passed to 
the receive loop once the slave acknow- 
ledges its address. 

The receive loop structure is patterned 
after that of the transmit procedure. The 
inner loop controls the clocking of the 
SCL line and the shifting of the serial da- 
ta off the SDA line into the CPU. Eight 
iterations of the inner loop are performed 
to receive each byte. The outer loop 
stores the received byte in the buffer, 
decrements the byte count, then sends 
an ACK to the slave. The last data byte 
is signalled by not sending an ACK. 

Using the Procedures 

Listing Three (page 110) shows a short 
program that uses both the master trans- 
mit and master receive procedures. The 
call to procedure I2C_XM1T displays the 
word "bUS-" on a four-character, sev- 
en-segment display controlled bv the 
SAA1064 I*C compatible display driver. 
The time of day is read from the 
PCF8583 real-time clock by the call to 
procedure I2C_RECV. 

Please note that interrupts must be 
disabled during the execution of both 
procedures. An interruption at an in- 
opportune time (when the master is not 
in control of the clock) could cause the 
bus to hang. If you need to service in- 
terrupts penodically, then enable them 
only when the dock is driven low. 

These procedures have been tested 
on a wide array of I^C devices ranging 
from senal EEPROMs to voice synthe- 
sizers. No compatibility problems have 
been seen to date. 

Enhancing ths Cods 

I've kicked around many ideas for en- 
hancing the I-C procedures. You could. 



All the basic 
building blocks of 
the I 2 C protocol 
(watching, waiting, 
and doing) can be 



into distinct macros 



for example, replace the timing loops 
with timed interrupts. That way, the CPU 
could perform useful work during the 
pauses. Along the same lines, the paus- 
es could be scheduled using a real- 
time kernel, again improving CPU 
throughput. Finally, you could add a 
high-level language calling structure. 

The use of timed interrupts adds an 
order of magnitude to the complexity 
of the code, but would be worth it for 
high-performance, real-time systems. 

Conclusion 

I^C is not the only game in town when 
in comes to serial protocols. Hopefully, 
some of the techniques presented here 
will carry over into the development of 
other "simulated" serial protocols, such 
as those targeted at the home-automa- 
tion market. Who knows, maybe some- 
day a snippet erf" my code may find its 
way into a truly intelligent dishwasher. 
I'll be waiting.... 
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